The present invention relates to testing systems, and more particularly, to a method for operating a computer to better control a test system for testing electrical components.
For the purposes of this discussion, a testing system is defined to be a system that applies various signals to a circuit or circuit element and measures the response of the circuit or element to those signals. Integrated circuit testers have been known to the art for some time. To perform tests, the testing system requires, among other data, a description of the tests to be performed and a description of the order in which the tests are to be executed.
There are several conventional techniques for specifying this information. In one type of system, the tests and test flow are described in a test program which controls the tester. Here, the description is embodied in a computer program in one of the conventional programming languages. The user must rely on a program provided by the test system manufacturer or be competent in programming. Further, each time the program is altered, the user must recompile the program. If the test system is being utilized in a quality control environment in which a large number of parts are being run through the same test, the programming overhead can be easily amortized. If, however, the testing system is being used to understand the performance of a few devices as part of a research and development program, the time needed to perform these programming tasks becomes significant. The required programming effort makes it difficult for an engineer to experiment with a device to ascertain detailed information that was not contemplated by the test system manufacturer.
The collection of data from a series of tests also presents problems with conventional test systems. In general, the test system will store the results of a specific test in a file for the user. The user is then left with the task of keeping track of the files. In many test situations, knowledge of the history of each device being tested is important to the understanding of the test results. Prior art systems do not provide a convenient method for storing this history. In principle, the user can use the date stamps on the test data files to keep track of the device history. However, this requires that each test protocol generate some sort of data file. If a particular test does not generate a test data file, the user has no way of determining the history of the device during testing. For example, consider a tester for ferroelectric capacitors. The response of each capacitor will often change over repeated data storage cycles. A capacitor tester typically measures the hysteresis loop for the capacitor and records the information in a file. Consider a test protocol consisting of measuring a hysteresis loop, cycling the capacitor through a number of storage cycles, and then measuring a second hysteresis loop. In a typical prior art test system, the cycling of the capacitor generates no data files, since nothing is measured during the cycling. Hence, the user must make some form of manual entry to keep track of this step.
In addition, the files generated by prior art test systems can be altered by the user. Hence, there is no guarantee that any given file contains the original test data after that file has been examined by several users over a long period of time.
In general, most testing regimens can be broken down into elementary tasks such as measuring a hysteresis loop for a capacitor as described above. Some subset of these elementary tasks is provided by the manufacturer of the test system. These tasks will, in general, require a computer programmer to generate the code needed to control the tester during the execution of the elementary task. If a user needs a new elementary task defined for a tester, the user is usually out of luck, unless he can interest the manufacturer in providing that new task. In most test systems, there is no easy method for inserting one new task. Hence, even if the manufacturer is willing to provide the code, the user must usually wait for some later update of the tester software. Further, the cost of providing the code for a new elementary task can be quite substantial. Accordingly, the manufacturer will not be willing to provide the code unless the task is one that a large number of users wants or the manufacturer can recoup the cost by spreading the cost over one or more users. Prior art test systems do not provide a convenient method for inserting new tasks that can only be used by users that have paid an additional fee for the privilege of using the task on the user""s tester. Hence, interesting a programmer or the manufacturer in coding a new test is difficult.
Broadly, it is the object of the present invention to provide an improved test system.
It is a further object of the present invention to provide a test system that allows the user to easily specify the tests to be performed on a device without being a computer programmer.
It is a still further object of the present invention to provide a test system that provides a convenient method for introducing new elementary tests into the test repertoire.
It is yet another object of the present invention to provide a test system that can utilize proprietary elementary test protocols while limiting the use of those protocols to specified users.
These and other objects of the present invention will become apparent to those skilled in the art from the following detailed description of the invention and the accompanying drawings.
The present invention is a method for operating a data processing system to control a device under test and to collect data from that device. The user is provided with a first display having a list of elementary tasks from which a user selects one or more elementary tasks using a pointing device. The task list includes first and second tasks. The first task applies a signal to the device under test when that task is executed by the data processing system and the second task causes the data processing system to receive data determined by the signals generated by the device under test. The invention also provides a second display from which the user can edit parameters in the tasks and from which the user can order the selected tasks to provide a current test definition. The user causes the system to execute a test based on the current test definition by selecting a graphical display element. The data processing system then executes each of the tasks in order in the current test definition and stores any data received from the device under test as a result thereof in a data set. The data set is displayed in a third display. Information specifying the current test definition is also stored in the data set. The list of elementary tasks can be expanded to include the current test definition as a new elementary task by dragging the current test definition from the second or third display to the first display. In the preferred embodiment of the present invention, the elementary tasks are constructed from objects in an object oriented computing model. The elementary tasks that collect data include a display method for displaying the data received from the device under test, which is invoked by selecting the elementary task in the third display. In the preferred embodiment of the present invention, the data processing system stores a system identification number. A third class of tasks includes a corresponding enabled identification number that restricts tasks of this class with respect to applying signals to the device under test and collects data therefrom to systems in which the enabled identification number matches the system identification number. Data sets may also be imported and exported to computer files. If a data set includes a task of the third class, an imported data set will still display the data in that task even on systems for which the task is not enabled with respect to data collection.